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ABSTRACT:  Link  16  is  a  Communications,  Navigation,  and  Identification  (CNI)  system,  intended  to  exchange 
surveillance  and  Command  and  Control  (C2)  information  among  various  C2  and  weapons  platforms,  which  enhance  the 
missions  of  each  service.  Links  16  provides  multiple  access,  high  capacity,  jam  resistant,  digital  data,  and  secure  voice 
CNI  information  to  a  variety  of  platforms.  Link  16  is  the  primary  NATO  standard  for  the  tactical  datalink.  NATO 
STANAG  5516/MIL-STD-6016  describes  the  TADIL  J  message  formats  and  Link  16  network  instructions. 

There  are  immediate  operational  requirements  for  existing  military  simulations  to  exchange  TADIL  J/Link  16  data  using  a 
single  interoperable  standard.  Several  protocols  have  evolved  to  satisfy  specific  needs.  The  NATO  STANAG  5602 
“SIMPLE”  Link  16  Standard  is  one  such  protocol.  The  standard  is  designed  to  be  complementary  to  the  SIMPLE  Standard. 
As  C2  distributed  simulation  expands  in  mission  scale  and  complexity,  tactical  datalink  implementations  need  to 
interoperate.  Currently,  there  are  five  different  Link  16  simulation  protocols,  and  none  interoperate.  Recently,  the 
Simulation  Interoperability  Standards  Organization  (SISO)  has  developed  a  Link  16  Simulation  Standard.  The  objective  of 
the  simulation  standard  is  to  establish  a  single  format  to  exchange  TADIL  J  messages,  and  emulate  a  Link  16  radio 
frequency  network  that  supports  Distributed  Missions  Operations  (DMO)  training  for  the  warfighter.  The  Air  Force 
Distributed  Mission  Operations  Center  of  Excellence  (DMOC)  located  at  Kirtland  AFB,  New  Mexico,  has  sponsored  these 
efforts  to  ensure  interoperability  between  C2  systems  in  the  DMO  training  environment. 

In  developing  a  standard  for  simulating  Link  16  in  Distributive  Interactive  Simulation  (DIS)  and  FTigh  Level  Architecture 
(F1LA),  it  is  recognized  that  there  are  widely  varying  requirements  for  achieving  fidelity  among  different  users.  The 
standard  attempts  to  establish  procedures  that  may  be  used  by  the  vast  majority  of  users,  by  establishing  discrete,  scalable, 
interoperable  levels  of  fidelity  for  different  users.  The  standard  also  defines  how  each  level  of  fidelity  interoperates; 
consequently,  allowing  a  low  cost  initial  implementation  with  a  path  toward  upgrading  to  higher  Link  16  simulation  as 
requirements  evolve. 

The  IEEE  1278.  la-1998  Standard  describes  established  DIS  Transmitter  and  Signal  Protocol  Data  Units  (PDUs),  but  they 
are  not  specifically  defined  for  Link  16  simulation.  The  SISO  Link  16  Standard  does  not  change  the  IEEE  1278. la-1998 
Standard  fields  for  the  Transmitter  or  Signal  PDUs,  but  exploits  the  fact  that  both  PDUs  are  variable  length.  For 
Transmitter  PDUs,  the  standard  defines  how  the  variable  length  modulation  parameter  fields  must  be  populated.  For  Signal 
PDUs,  Link  16  specific  information  is  relegated  to  the  variable  length  data  fields.  In  addition.  Link  16  specific 
enumerations  have  been  created  to  populate  the  standard  fields. 

The  FILA  instructions  are  formatted  in  compliance  with  the  IEEE  1516  Standard  for  F1LA.  The  instructions  are  presented 
in  the  form  of  a  Base  Object  Model  (BOM)  that  may  be  incorporated  into  a  system  FOM.  RPR-FOM  based  simulations 
should  be  able  to  easily  integrate  the  Link  16  BOM  into  their  FOMs.  Furthermore,  there  is  a  straightforward  mapping 
between  the  DIS  PDU  implementations  and  the  corresponding  BOM  components. 


This  paper  presents  the  Link  16  DIS  Transmitter  and  Signal  PDU  structures,  FILA  FILA  BOM  Object  Model  Templates 
(OMTs),  general  requirements,  and  implementation  guidelines  that  provide  interoperability  among  C2  systems. 


1.  Scope 


This  paper  describes  the  protocol  that  establishes  a  standard  for  TADIL-J  message  exchange  and  JTIDS  network 
simulation  in  the  DIS  and  HLA  interoperability  frameworks.  The  intent  is  to  describe  the  content  of  the  standard  fields  of 
the  Transmitter  and  Signal  PDUs  and  establish  procedures  for  their  use.  Compliance  with  these  procedures  will  ensure 
interoperability  amongst  JTIDS  simulation  systems.  Additional  detail  can  be  found  in  Reference  1. 
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4.  NATO  STANAG  5602,  edition  1,  Standard  Interface  for  Multiple  Platform  Link  Evaluation  (SIMPLE)  20  Feb 
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5.  System  Segment  Specification  for  Joint  Tactical  Information  Distribution  System  Class  2  Terminal,  15  April  1999 

6.  STANAG  5516,  Edition  1,  Tactical  Data  Exchange  -  LINK  16,  Ratified  15  January  1997. 
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8.  Joint  Interoperability  of  Tactical  Command  and  Control  Systems  Variable  Message  Format  (VMF)  Technical 
Interface  Design  Plan  (Test  Edition)  Reissue  2,  August  1996. 

3.  JTIDS  Operating  Characteristics 

JTIDS  uses  the  principle  of  frequency  hopping  Time  Division  Multiple  Access  (TDMA)  to  divide  network  time,  and 
capacity,  into  divisions  called  time  slots.  Each  time  slot  is  7.8125  milliseconds  long  with  128  time  slots  per  second.  Time 
slots  are  organized  into  three  interleaved  sets  (A,  B,  and  C).  An  epoch  is  12.8  minutes  long  comprised  of  32K  time  slots. 
There  are  1 12.5  epochs  in  a  24-hour  day.  Therefore,  the  current  epoch,  set  and  time  slot  number  can  be  calculated  from  the 
current  time.  Operationally,  groups  of  time  slots  are  assigned  to  a  common  function  known  as  a  Network  Participation 
Group  (NPG).  Time  slot  assignments  are  published  in  a  network  data  load  (by  a  central  net  design  agency),  with 
participation  groups  identified  by  the  time  slot  set,  the  “offset”  of  the  time  slot,  and  the  time  slot  repetition  rate.  The 
repetition  rate  is  expressed  as  an  exponential  power  of  2,  representing  how  often  the  time  slot  assigned  to  the  NPG  occurs 
within  the  set. 

TDMA  architecture  requires  that  each  JTIDS  participant,  known  as  a  JTIDS  Unit  (JU),  must  know  when  its  transmit  time 
slots  occur.  JUs  must  be  synchronized  with  a  common  network  time  to  receive  and  transmit  on  the  network.  In  JTIDS,  one 
JU  in  a  network  is  designated  as  the  Network  Time  Reference  (NTR). 

4.  General  Requirements 

This  section  describes  general  requirements  for  simulation  of  Link  16  independent  of  the  simulation  protocol  used.  The 
specific  implementation  under  DIS  is  described  in  section  5.  The  specific  requirements  for  implementation  under  HLA  are 
described  in  section  6. 

1.  Simulators  in  compliance  with  this  standard  shall  at  a  minimum  have  the  capability  to  identify  the  NPG  and  net 
number  of  transmitted  data  to  allow  them  to  operate  at  TSA  mode  level  0  and  1 . 

2.  All  TADIL  J  messages  shall  be  bit  encoded  in  accordance  with  the  MIL-STD-6016  TADIL  J  specification.  In  the 
specification,  each  time  slot  contains  one  35-bit  header,  padded  to  48  bits,  and  a  varying  number  of  75  bit  messages, 
padded  to  80  bits,  unless  the  message  type  indicator  specifies  otherwise. 

3.  Regardless  of  level  of  fidelity,  all  transmission  modulation  parameter  fields  shall  be  filled  with  meaningful  data 

4.  When  the  header  indicates  Reed-Solomon  encoding,  the  data  area  shall  still  be  comprised  of  non  Reed-Solomon 
encoded  TADIL  J  messages. 

5.  Any  simulator  that  is  not  emulating  JTIDS  network  data  load  throughput  shall  have  the  ability  to  configure  the 
maximum  number  of  JTIDS  words  transmitted  per  second,  but  shall  not  exceed  the  JTIDS  maximum  of  1536  J-words 


per  second  (twelve  J-words  per  Pack-4  Single  Pulse  time  slot  multiplied  by  128  time  slots  per  second).  This  upper  limit 
shall  not  apply  to  JTIDS  LET  (Enhanced  Throughput)  packets. 

6.  If  the  packing  mode  from  the  JTIDS  header  and  the  number  of  messages  contained  in  the  Signal  message  do  not  agree, 
(i.e.  the  header  states  that  the  packing  mode  is  Pack-2  Double  Pulse  and  there  are  12  J-words  contained  with  the 
message)  extra  messages  shall  be  dropped  by  the  receiving  simulator — as  would  happen  in  a  live  JTIDS  datalink. 
Simulators  should  be  able  to  determine  if  the  number  of  messages  in  the  header  matches  the  actual  number  of  TADIL  J 
messages.  If  there  are  fewer  messages  in  the  data  area  than  prescribed  by  the  packing  mode,  the  receiver  shall  treat  the 
missing  messages  as  J31.7  “No  statement”  messages  and  parse  the  message  stream  accordingly. 

7.  Systems  shall  wait  until  the  time  slot  occurs  to  transmit  data  in  order  to  receive  the  latest  update  to  data  (i.e.  time  slots 
shall  not  be  “pre-sent”).  Receiving  systems  shall  buffer  messages  after  the  time  slot  has  occurred  to  account  for 
network  delays.  The  amount  of  time  to  buffer  messages  for  a  time  slot  shall  be  a  runtime  configuration  item.  The 
amount  of  time  entered  shall  be  the  same  for  all  participants  in  the  same  network  and  will  cause  the  simulations  to  all 
“retire”  a  particular  time  slot  at  the  same  time.  This  effect  is  not  important  for  lower  levels  of  fidelity  (Time  Slot 
Allocation  (TSA)  modes  0,  1)  but  is  critical  for  all  fidelity  levels  that  tie  a  message  to  a  particular  time  slot  along  with  a 
Network  Data  Load  (NDL).  If  the  effects  of  messages  arriving  later  than  the  time  slot  are  not  important  (multiple  JUs 
transmitting  in  the  same  time  slot,  contention  access,  or  data  arriving  while  the  receiving  JU  is  transmitting),  or  the 
physical  network  infrastructure  has  low  delays  (less  than  3  msec),  the  buffer  time  can  be  set  to  a  low  number  or  to  zero. 

8.  All  systems  set  at  TSA  level  2  or  higher  shall  have  their  system  times  synchronized  to  a  common  time  reference.  Any 
error  in  the  clock  synchronization  times  (e.g.  average  NTP  error)  must  be  added  to  the  network  delays  (the  buffer  time) 
before  retiring  a  time  slot.  For  real-time  DIS  or  HLA  simulation  applications,  NTP  (or  equivalent)  is  recommended.  For 
non-real-time  simulation  applications,  HLA  time  management  is  recommended. 

9.  All  systems  should  have  some  representation  of  a  terminal  clock  time.  If  medium  fidelity  synchronization  is  to  be 
accomplished,  the  system  shall  model  a  terminal  clock  (and  its  associated  drift). 

10.  At  TSA  level  2  or  greater,  if  multiple  messages  are  received  with  identical  TSEC,  net  number  and  timeslot  number, 
receivers  shall  not  process  messages  except  from  the  closest  transmitting  entity  (in  the  simulation  space). 

11.  There  are  three  communication  modes  for  a  real  JTIDS/MIDS  network:  modes  1,  2  and  4  (See  Table  1).  The  selected 
communication  mode  determines  whether  or  not  the  network  can  operate  on  multiple  nets  (by  employing  frequency 
hopping)  and  the  transmitted  data  are  encrypted.  All  JUs  in  a  JTIDS/MIDS  network  must  operate  in  the  same 
communication  mode. 


Table  1.  JTIDS  Communication  Modes 


Communication  Mode 

Frequency 

Hopping 

Data  Encrypted 

1 

Yes 

Yes 

2 

No 

Yes 

3 

Not  Used 

Not  Used 

4 

No 

No 

12.  The  normal  JTIDS  communication  mode  is  mode  1.  Frequency  hopping  and  crypto  variables  are  simulated  appropriate 
to  the  specified  level  of  fidelity. 

13.  When  operating  with  JTIDS  communication  mode  2,  there  will  be  no  frequency  hopping,  but  encryption  shall  still  be 
used,  depending  on  the  level  of  fidelity.  The  explicit  frequency  of  969  MHz  shall  be  set  in  the  transmission  message 
frequency  field  and  the  bandwidth  will  be  3MHz.  The  net  number  in  the  signal  message  shall  be  zero  for  all 
transmissions  (no  multi-netting). 

14.  Mode  4  eliminates  communications  security  in  addition  to  the  features  of  communications  mode.  The  encryption  fields 
shall  be  set  to  0  when  in  communications  mode  4  in  addition  to  specifying  the  explicit  transmit  frequency  as  in 
communications  mode  2. 

15.  Time  slots  shall  be  numbered  sequentially,  such  that  time  slot  0  represents  time  slot  A-l,  time  slot  98303  represents  C- 
32767.  When  the  epoch  is  112,  the  last  valid  time  slot  is  45151  (end  of  the  day). 


16.  Generated  machine  receipts  shall  use  time  slots  as  assigned  in  the  network  description.  There  is  no  special 
consideration  given  to  machine  receipts;  they  are  treated  as  any  other  TADIL  J  fixed  format  message. 

17.  Relay  is  accomplished  by  transmitting  relay  information  in  assigned  time  slots.  There  is  no  special  mechanism 
necessary  to  simulate  relay  transmissions. 

18.  Transmission  messages  shall  only  be  sent  with  signal  messages  in  conjunction  with  the  following  events:  entering  the 
Link  16  network,  exiting  the  Link  16  network,  during  synchronization  state  changes,  with  PPL!  messages,  and  with 
initial  net  entry  messages. 

4.1  Levels  of  Fidelity 

This  protocol  allows  simulations  to  achieve  different  levels  of  fidelity  by  assigning  one  of  five  Time  Slot  Allocation  (TSA) 
levels.  If  the  simulator  allows  for  a  settable  level  of  fidelity,  the  level  of  fidelity  shall  be  set  at  runtime.  The  TSA  level 
shall  be  set  in  Modulation  Parameter  #1  of  the  transmission  packet  with  an  enumeration  of  0-4  as  described  in  Table  2. 


Table  2:  JTIDS  Levels  of  Fidelity 


TSA 

Level 

Fidelity 

Synchronization 

Fidelity 

Issues 

Recommended  Usage 

0 

Low 

Low 

Does  not  emulate  JTIDS 
network  characteristics.  Data 
rates  are  not  constrained. 
Intended  for  legacy  use. 

Experiments  and/or  training  concerned  with 
message  format  and/or  message  content 
only. 

1 

Low 

Low 

Does  not  emulate  JTIDS 
network  characteristics. 

Allows  for  bandwidth  throttling  to  emulate 
JTIDS  network  throughputs  without 
assigning  messages  to  specific  time  slots. 

Net  Data  Loads  can  be  loaded  into  terminal 
simulation  equipment  to  simulate  data  rates 
in  NPGs  on  the  Link  16  network. 

2 

Medium 

Low 

Network  delay  must  be 
sufficiently  small  if  time  slot 
sensitive  conversations  are 
required  to  duplicate  live 

Link  16  networks  (e.g.  relay 
emulation,  RELNAV, 
messages  requiring 
responses). 

Experiments  and/or  training  concerned  with 
throughput  limits  of  the  Link  16  network. 
Also  suitable  for  experiments/training 
emulating  message  traffic  and  timing  of 
JTIDS  networks  without  emulating  effects 
of  RTTs,  RELNAV,  or  stacked/multi-nets. 

3 

Medium 

Low 

Same  as  TSA  Level  2. 

Experiments  and/or  training  concerned  with 
emulating  stacked-,  multi-,  and  crypto-  net 
emulation. 

4 

High 

Medium 

Extremely  sensitive  to 
network  latency. 

Experiments  and/or  training  concerned  with 
effects  deriving  from  emulation  of  network 
entry  and  synchronization  maintenance. 

TSA  level  0  is  the  lowest  level  of  fidelity.  The  NPG  and  net  fields  are  filled  in  the  signal  message,  but  all  other  data  in  the 
JTIDS  transmission  header  is  set  to  the  default  value.  Multiple  messages  are  permitted  in  a  single  Signal  message.  All 
messages  within  the  signal  message  are  assumed  to  be  for  the  same  NPG  and  Net  with  the  same  assumed  packing.  There  is 


no  TSA  or  metering  with  up  to  the  maximum  number  of  messages  (as  specified  in  the  DIS  standard)  packed  into  the  data 
area  of  a  single  signal  message. 

TSA  Level  1  is  similar  to  TSA  Level  0  except  that  there  is  minimal  metered  data.  When  the  TSA  level  is  set  to  one,  one 
time  slot  worth  of  information  shall  be  in  one  Signal  message.  As  in  TSA  level  0,  the  NPG  and  net  fields  are  filled  in,  and 
the  rest  of  the  transmission  information  is  set  to  default. 


TSA  Level  2  allows  for  metered  data  with  no  encryption.  When  the  TSA  level  is  set  to  2,  messages  shall  be  assigned  to 
individual  time  slots.  The  NPG,  net,  and  time  slot  identification  fields  are  filled  in.  The  TSEC  and  MSEC  are  set  to 
default.  This  level  enables  full  TSA  to  include  Encryption.  When  TSA  mode  is  set  to  3,  stacked  nets,  multi-nets,  and 
crypto-nets  can  be  emulated.  All  transmission  information  fields  are  filled  in.  Low  fidelity  synchronization  is  achieved  in 
accordance  with  paragraph  5.3.1. 


TSA  Level  4,  everything  from  TSA  3  is  emulated,  with  the  addition  of  the  medium  fidelity  synchronization  procedures.  All 
JTIDS  header  fields  in  the  signal  message  shall  be  filled  with  non-default  meaningful  values.  Medium  fidelity 
synchronization  is  achieved  in  accordance  with  paragraph  5.3.2. 

4.2  Communication  between  JUs  with  different  fidelity  levels 

In  the  event  that  participants  in  a  simulated  JTIDS  network  cannot  set  their  respective  simulations  to  operate  at  a  common 
level  of  fidelity  (i.e.  TSA  Level)  the  following  procedures  apply: 

If  a  low  fidelity  network  participant  is  in  a  simulated  JTIDS  network  with  a  higher  fidelity  NTR,  the  network  participant 
shall  follow  the  low  fidelity  synchronization  procedures  in  paragraph  5.3.1  by  skipping  the  RTT  synchronization  process 
and  changing  directly  to  the  fine  synchronization  state  once  it  receives  a  JO.O  Initial  Entry  message  from  the  NTR  or  any 
IEJU. 

If  a  higher  fidelity  network  participant  is  in  a  simulated  JTIDS  network  with  a  lower  fidelity  NTR,  the  higher  fidelity 
participant  shall  either  follow  the  low  fidelity  synchronization  procedures  in  paragraph  5.3  or  achieve  fine  sync  with  other 
high  fidelity  simulators.  This  can  be  accomplished  by  exchanging  RTT  B  messages  or  by  passively  synchronizing  with 
other  available  high  fidelity  simulators.  If  no  other  high  fidelity  simulators  are  available  to  synchronize  with,  the  high 
fidelity  participant  shall  skip  the  RTT  exchange,  and  directly  enter  fine  synchronization  once  the  JO.O  is  received. 

If  the  NTR  is  a  lower  fidelity  simulation  and  unable  to  simulate  full  NTR  duties,  the  NTR  shall  still  have  the  ability  to 
transmit  net  entry  messages.  The  signal  message  shall  be  filled  in  with  a  JO.O  with  zeroed  time  slot  information.  RTT 
emulation  will  not  be  required  of  low  fidelity  NTRs. 

A  lower  fidelity  JU  entering  the  net  shall  use  the  network  synchronization  ID  received  from  the  NTR/IEJU  in  its 
Transmitter  messages.  It  will  then  issue  PPLIs  at  the  assigned  rate.  This  is  nominally  once  every  12  seconds  (equivalent  to 
the  A-0-6  time  slot  block),  though  this  can  occur  at  times  of  up  to  24  seconds.  All  simulators,  regardless  of  fidelity,  shall 
accept  another  terminal’s  statement  of  synchronization  capability  if  the  network  synchronization  ID  matches  its  own 
network  synchronization  ID. 

In  a  lower  fidelity  synchronization  simulation,  non-reception  of  a  PPLI  message  pair  for  60  seconds  shall  indicate  that  the 
unit  has  fallen  out  of  the  datalink.  Synchronization  procedures  shall  be  re-accomplished — reception  of  a  PPLI  message 
stating  fine  synchronization  must  occur  before  data  from  the  JU  will  be  accepted. 

4.3  Time  Synchronization 

For  TSA  Level  0-2,  the  Network  Synchronization  shall  be  set  to  zero.  For  TSA  Level  3-4,  the  Network  Synchronization 
IDs  shall  be  a  32  bit  unsigned  integer  uniquely  generated  by  the  NTR.  The  NTR  shall  use  either  a  non-deterministic 
random  number  generator  or  a  pseudo-random  number  generator  using  the  timestamp  of  the  time  they  begin  to  simulate  a 
NTR  as  the  random  key  seed.  If  using  a  seed  based  pseudo-random  number  generator,  use  the  NTR  selection  time  with 
precision  equivalent  to  Network  Time  Protocol  (NTP)  as  the  seed.  Seedless  random  number  generators  are  encouraged;  the 
goal  is  to  make  sure  that  all  NTRs  have  unique  synchronization  IDs  in  the  transmitter  PDU. 

If  a  system  in  the  real  world  is  capable  of  acting  as  NTR,  any  corresponding  simulator  shall  also  be  capable,  at  a  minimum, 
of  acting  as  a  low  fidelity  NTR. 


If  no  simulators  in  a  simulated  JTIDS  net  are  capable  of  acting  as  a  NTR,  participants  shall  be  able  to  set  the  network 
synchronization  ID  to  zero  and  transmit  the  synchronization  state  of  fine  synchronization.  A  zero  in  the  network 
synchronization  ID  field  shall  be  accepted  as  a  wildcard  matching  any  network  synchronization  ID. 

If  a  network  synchronization  ID  accompanying  received  data  does  not  match  a  JU’s  own  network  synchronization  ID,  the 
data  shall  be  considered  as  having  not  been  received. 

Simulated  terminals  shall  accept  net  entry  messages  (J0.0)  from  any  simulated  transmitting  terminal  within  reception 
range.  When  medium  fidelity  synchronization  is  applicable  (TSA  Mode  level  4),  and  the  net  entry  message  has  a  network 
synchronization  ID  different  than  the  local  network  synchronization  ID,  the  JU  shall  revert  back  to  coarse  synchronization, 
use  the  new  network  synchronization  ID,  cease  sending  TADIL  J  data  and  attempt  re-synchronization  with  the  new 
network  in  accordance  with  the  JTIDS  terminal  specification.  If  the  network  synchronization  ID  (i.e.  during  changeover  of 
NTR  or  multiple  IEJUs)  is  the  same  as  the  locally  held  key,  the  JU  will  not  revert  to  coarse  synchronization  status  and  will 
not  stop  transmitting  TADIL  J  data. 

If  an  initial  net  entry  message  is  received  from  a  unit  that  does  not  have  a  Transmitting  Terminal  Primary  Mode  of  IEJU  or 
NTR,  it  shall  still  be  accepted.  Depending  upon  implementation,  the  simulation  operator  may  be  notified  so  that  the 
sending  simulator  can  correct  this  error  condition. 

All  simulators  shall  have  at  least  a  low  fidelity  simulation  of  a  terminal  clock,  potentially  independent  of  the  simulator’s 
(or  live  equipment’s)  clock.  Since  whatever  time  an  NTR  has  set  is  considered  correct,  an  NTR  may  transmit  a  time  that 
significantly  varies  from  the  actual  simulated  wall  clock.  In  high  fidelity  simulation  systems  the  terminal  clock  may  model 
the  clock  drift  of  an  actual  JTIDS  terminal.  It  is  not  expected  that  terminal  clocks  will  be  modeled  at  a  high  level  of  fidelity 
and  the  actual  level  of  emulation  is  left  to  the  implementer. 

4.3.1  Low  Fidelity  Synchronization 

Low  fidelity  synchronization  is  applicable  to  simulation  systems  interested  primarily  in  providing  tactical  datalink 
information  as  part  of  an  operational  scenario.  The  low  fidelity  synchronization  procedure  allows  such  systems  to  exchange 
Link  16  messages  without  being  encumbered  by  actual  JTIDS  transmission  and  message  security  requirements. 

The  NTR  shall  begin  by  issuing  Net  Entry  message  pairs  at  a  rate  in  accordance  with  the  JTIDS  terminal  specification 
(typically  in  time  slot  A-0-6  at  a  rate  of  every  12  seconds).  A  unique  randomly  generated  key  shall  be  filled  into  the 
network  synchronization  ID  field.  The  primary  JTIDS  duty  field  shall  contain  a  NTR  enumeration. 

Modulation  Parameter  4  (Synchronization  State)  in  the  transmission  message  shall  be  set  to  “fine  synchronization”  after 
reception  of  the  JO.O  Initial  Net  Entry  message  from  the  IEJU  or  NTR.  The  first  data  message  that  will  be  sent  by  a  JU 
entering  the  network  shall  be  the  JU’s  PPLI. 

4.3.2  Medium  Fidelity  Synchronization 

Medium  Fidelity  Synchronization  corresponds  to  only  the  high  fidelity  TSA  level  4.  It  is  applicable  to  those  systems  for 
which  simulation  of  the  fine  synchronization  methodology  is  paramount,  potentially  for  high  fidelity  training,  network 
testing  and  network  experimentation.  Because  the  latency  of  WANs  (latencies  up  to  hundreds  of  milliseconds)  is  orders  of 
magnitude  higher  than  in  a  real  Link  16  network  (latencies  up  to  3ms),  this  methodology  will  not  meet  the  needs  of  sub¬ 
millisecond  accuracy. 

Communities  with  the  need  for  sub-millisecond  accuracy  will  need  to  use  a  centralized  server  on  a  real-time  operating 
system  to  simulate  the  microsecond  intricacies  of  the  JTIDS  network.  The  term  “High  Fidelity  Synchronization”  will  be 
reserved  for  synchronization  mechanisms  that  are  able  to  model  the  sub-millisecond  accuracy  of  the  Link  16  network. 

The  accuracy  of  the  synchronization  mechanism  shall  have  an  error  less  than  the  simulated  time  of  propagation.  The 
accuracy  of  the  synchronization  mechanism  must  be  taken  into  account  when  modeling  fine  synchronization. 

The  Medium  Fidelity  Synchronization  procedure  is  as  follows:  First,  the  NTR  shall  begin  by  issuing  Net  Entry  message 
pairs  at  a  rate  in  accordance  with  the  JTIDS  terminal  specification  (typically  in  time  slot  A-0-6  at  a  rate  of  every  12 
seconds).  A  unique  randomly  generated  key  shall  be  filled  into  the  network  synchronization  ID  field.  The  primary  JTIDS 
duty  field  shall  contain  a  NTR  enumeration.  At  this  point,  the  JU  is  considered  to  have  achieved  “coarse  synchronization.” 


The  JU  shall  then  transmit  the  appropriate  RTT  message  (A  or  B).  The  synchronization  state  shall  be  set  to  “coarse 
synchronization.”  The  JU  shall  use  its  own  terminal  perceived  time  in  the  perceived  transmit  time  field.  The  appropriate 
NTR/JU  will  answer  (in  accordance  with  the  JTIDS  terminal  specification),  using  the  JU  perceived  time  and  the  entity 
distance  to  calculate  the  perceived  receive  time.  The  RTT  is  then  transmitted.  The  transmitting  JU  shall  fill  its  own 
terminal  perceived  time  with  the  received  transmit  time  field.  The  formula  for  filling  in  the  receive  time  in  the  RTT  reply 


is: 


RTT  —  RT 

1X1  1  reply  terminal 


-t 


delay 


+  t 


propagate 


i.  The  t deiay  is  computed  by:  tdelay  =  RTdme  -  TTtime 
b.  Where 

RTtime  is  the  actual  time  held  by  the  receiving/replying  participant  (Derived  from  NTP,  GPS,  etc) 

RT  terminal  is  the  value  of  the  simulated  Link  16  terminal  clock  at  the  receiving/replying  participant 

TTtime  is  the  actual  time  held  of  transmitting  participant  (Derived  from  NTP,  GPS,  etc) 

tdelay  is  the  difference  between  the  receiver’s  real-time  clock  at  the  time  of  receipt  and  the  sender’s  real¬ 
time  clock  at  the  time  of  transmission  (i.e.  it  approximates  the  emulation  network  latency),  and 

tpropagate  is  the  propagation  time  of  the  radio  frequency  message  in  the  simulated  environment. 

This  formula  computes  the  perceived  time  of  receipt  by  the  receiving  simulator  with  respect  to  the  simulated  terminal  clock 
of  the  sender. 


The  originating  JU  shall  then  update  its  own  terminal  time  in  accordance  with  the  simulator  model  and  the  Link  16  fine 
synchronization  procedures.  After  the  appropriate  number  of  RTT  exchanges  have  occurred  (depending  whether  the  RTT 
A  or  RTT  B  method  of  synchronization  was  used  and  the  internal  terminal  simulation  model),  the  JU  shall  consider  itself  to 
be  in  fine  synchronization  and  shall  continually  issue  RTT  message  pairs  to  maintain  synchronization  at  rates  specified 
within  the  JTIDS  terminal  specification.  Once  the  terminal  emulator  model  has  met  the  requirements  for  fine 
synchronization,  normal  message  transmissions  occur  in  accordance  with  Ref.  7  and  Ref.  10. 

5  JTIDS  implementation  under  DIS 


This  section  contains  the  requirements  for  simulation  of  JTIDS  using  the  DIS  Signal  and  Transmitter  PDU.  For  the  DIS 
Protocol  Profiles,  transmission  and  receipt  of  PDUs,  and  general  service  requirements,  refer  to  Reference  1.  In 
implementing  the  Signal  PDU,  perceived  data  should  be  able  to  be  sent  on  a  configurable  port  separate  from  all  other  DIS 
data.  This  allows  datalinks  to  be  selectively  routed  without  additional  hardware.  This  also  allows  for  gateways  to  forward 
data  between  legacy  DIS  datalink  formats  and  the  new  standardized  format. 

5.1  Transmitter  PDU  Description 

Table  3  shows  the  format  for  the  Transmitter  PDU  for  JTIDS  simulation. 


Table  3:  Transmitter  PDU  for  TADIL  J 


Field  Size 
(bits) 

Transmitter  PDU  Fields 

Description* 

96 

PDU  Header 

Protocol  Version 

8  bit  enumeration 

Exercise  ID 

8  bit  unsigned 
integer 

PDU  Type 

8  bit  enumeration 

Protocol  Family 

8  bit  enumeration 

Timestamp 

32  bit  unsigned 
integer 

Table  3:  Transmitter  PDU  for  TADIL  J 


Field  Size 
(bits) 

Transmitter  PDU  Fields 

Description* 

Length 

16  bit  unsigned 
integer 

Padding 

16  bits  unused 

48 

Entity  ID 

Site 

16  bit  unsigned 
integer 

Application 

16  bit  unsigned 
integer 

Entity 

16  bit  unsigned 
integer 

16 

Radio  ID 

16  bit  unsigned 
integer 

Shall  contain  the  ID  of  the  radio 
transmitting  the  signal. 

64 

Radio  Entity 
Type 

Entity  Kind 

8  bit  enumeration 

Domain 

8  bit  enumeration 

Country 

16  bit  enumeration 

Category 

8  bit  enumeration 

21  -  Link  16  terminal  IAW  Ref.  4 
para  4. 2. 3. 7 

Nomenclature 

Version 

8  bit  enumeration 

Nomenclature 

16  bit  enumeration 

8 

Transmit  State 

8  bit  enumeration 

8 

Input  Source 

8  bit  enumeration 

8  -  Digital  Data  Device 

16 

Padding 

16  bits  unused 

192 

Antenna 

Location 

X  component 

64  bit  floating  point 

Y  component 

64  bit  floating  point 

Z  component 

64  bit  floating  point 

96 

Relative 

Antenna 

Location 

x  component 

32  bit  floating  point 

y  component 

32  bit  floating  point 

z  component 

32  bit  floating  point 

16 

Antenna 
Pattern  Type 

16  bit  enumeration 

16 

Antenna 

Pattern 

Length 

16  bit  unsigned 
integer 

64 

Frequency 

64  bit  unsigned 
integer 

Mode  1  =  1131000000  (center 
frequency).  For  Mode  2  or  4,  set 
to  969000000 

32 

Transmit 

Frequency 

Bandwidth 

32  bit  floating  point 

240000000  unless  in 
Communications  mode  2  or  4, 
then  3000000 

32 

Power 

32  bit  floating  point 

Power  in  dBm 

64 

Modulation 

Type 

Spread  Spectrum 

16  bit  Boolean  array 

Bit  1  set  to  1:  Frequency 

Flopping  for  JTIDS 
communications  mode  1 . 

All  bits  set  to  0:  For  JTIDS 
communications  modes  2  or  4 

Table  3:  Transmitter  PDU  for  TADIL  J 


Field  Size 
(bits) 

Transmitter  PDU  Fields 

Description* 

Major 

16  bit  enumeration 

7  -  Carrier  Phase  Shift 

Modulation  (CPSM) 

Detail 

16  bit  enumeration 

0  -  Other 

System 

16  bit  enumeration 

8  -  JTIDS/MIDS 

16 

Crypto 

System 

16  bit  enumeration 

0  -  Other 

16 

Crypto  Key 

ID 

16  bit  unsigned 
integer 

8 

Length  of 

Modulation 

Parameters 

8  bit  unsigned 
integer 

8=  8  octets 

24 

Padding 

24  bits  unused 

8 

Modulation 
Parameter  #  1 

Time  Slot 
Allocation  Mode 

8  bit  enumeration 

Integer  enumeration  0-4 

8 

Modulation 
Parameter  #2 

Transmitting 

T erminal  Primary 
Mode 

8  bit  enumeration 

Integer  Enumeration: 

1  -  NTR 

2  -  JTIDS  Unit  Participant 

8 

Modulation 
Parameter  #3 

Transmitting 

T  erminal 
Secondary  Mode 

8  bit  enumeration 

Integer  Enumeration: 

0  -  None 

1  -  Net  Position  Reference 

2  -  Primary  Navigation 

Controller 

3  -  Secondary  Navigation 
Controller 

8 

Modulation 
Parameter  #4 

Synchronization 

State 

8  bit  enumeration 

Integer  Enumeration: 

2  -  Coarse  Synchronization 

3  -  Fine  Synchronization 

32 

Modulation 
Parameter  #5 

Network 

Synchronization 

ID 

32  bit  unsigned 
integer 

TSA  Level  0-2,  set  to  0 

TSA  Level  3,4,  set  to  32  bit 
random  number 

Transmitter  PDUs  used  in  Link  16  simulation  shall  include  all  of  the  standard  information,  as  well  as  the  information 

described  in  the  modulation  fields.  The  Transmitter  PDU  shall  contain  the  following  fields: 

1.  The  Radio  Entity  Type  Category  field  shall  be  set  to  21  for  Link  16  terminal. 

2.  The  Input  Source  field  shall  be  set  to  8  for  Digital  Data  Device. 

3.  Frequency.  This  field  shall  specify  the  JTIDS  center  frequency  of  1131000000  for  communications  mode  1.  For 
communications  mode  2  or  4,  a  frequency  of  969000000  shall  be  used. 

4.  Transmit  Frequency  Bandwidth.  This  field  shall  contain  the  bandwidth  of  the  JTIDS  signal,  simulating  the  use  of  the 
entire  frequency  band  as  an  average  over  time.  The  field  shall  be  represented  by  a  32-bit  float  value  of  240000000, 
unless  operating  in  communications  mode  2  or  4,  and  then  a  value  of  3000000  shall  be  used. 

5.  Modulation  Type.  The  Modulation  Type  fields  contain  enumerations  for  the  major  and  detail  modulation  fields: 

a.  The  Spread  Spectrum  field  is  a  16-bit  Boolean  array,  and  shall  be  set  to  1  for  frequency  hopping  only  for 
JTIDS  communications  mode  1.  For  modes  2  or  4,  the  Spread  Spectrum  field  shall  be  set  to  0. 


b.  The  Major  modulation  field  is  a  16-bit  enumeration,  and  shall  be  set  to  7  for  Carrier  Phase  Shift  Modulation. 

c.  The  Detail  modulation  field  is  a  16-bit  enumeration,  and  shall  contain  a  0. 

d.  The  System  field  is  a  16-bit  enumeration,  and  shall  be  set  to  8  for  JTIDS/MIDS 


6.  Crypto  System.  For  Link  16  simulation  under  this  standard  this  field  shall  be  set  to  zero. 

7.  Crypto  Key  ID.  For  Link  16  simulation  under  this  standard  this  field  shall  be  set  to  zero. 

8.  Length  of  Modulation  Parameters.  These  fields  shall  specify  the  length  in  octets  of  the  modulation  parameters  that 
follow  this  field.  This  length  shall  be  set  to  8,  representing  8  octets  for  the  DIS  J  Transmitter  PDU. 

9.  Modulation  Parameters.  These  fields  shall  specify  the  modulation  type  specific  characteristics  of  the  Transmitter  PDU. 

a.  Modulation  Parameter  1  shall  contain  the  TSA  mode  with  an  enumeration  of  0-4  for  TSA  level  0-4  as 
described  in  section  4.1. 

b.  Modulation  Parameter  2  shall  contain  the  transmitting  terminal’s  primary  mode.  Setting  the  enumeration  to  1 
shall  indicate  that  the  entity  is  the  NTR.  Setting  it  to  2  shall  indicate  that  the  entity  is  a  JU  participant. 

c.  Modulation  Parameter  3  shall  contain  the  transmitting  terminal’s  secondary  mode,  with  the  following 
enumerations:  0=None,  l=Net  Position  Reference,  2=Primary  Navigation  Controller,  3=Secondary 
Navigation  Controller. 

d.  Modulation  Parameter  4  shall  contain  the  synchronization  state.  For  TSA  mode  level  0-3  this  shall  be  set  to  3 
for  “fine”  synchronization.  For  TSA  level  4,  it  is  initially  set  to  2  for  “coarse”  synchronization  and  the 
procedures  in  section  4.3.2  for  medium-level  synchronization  are  followed. 

e.  Modulation  Parameter  5  shall  contain  the  Network  Synchronization  ID.  For  TSA  modes  0-2,  it  shall  be  set  to 
default.  For  TSA  modes  3-4,  it  shall  be  a  32-bit  random  integer.  Only  an  NTR  can  generate  a  Network 
Synchronization  ID;  all  other  participants  shall  use  the  ID  obtained  from  the  NTR  to  which  they  are 
synchronized. 

5.2  Signal  PDU  Description 

The  Signal  PDU  includes  all  standard  fields  as  described  in  Reference  2.  Examples  of  the  Signal  PDU  for  TSA  Levels  0-3 

are  found  in  Reference  1,  Annex  B. 

When  used  for  Link  16  simulation  the  following  specific  information  is  required: 

1.  Entity  and  Radio  ID.  These  fields  shall  contain  the  ID  of  the  entity  and  radio  transmitting  the  signal.  Radios  are 
numbered  sequentially  starting  with  1 . 

2.  Encoding  scheme.  Bits  0-13  shall  contain  the  number  of  J-words  not  including  the  JTIDS  header.  Bits  14-15  shall 
contain  the  value  1  to  indicate  an  encoding  class  raw  binary  data. 

3.  TDL  Type.  This  field  shall  specify  the  TDL  type  as  a  16-bit  enumeration  field,  and  shall  be  set  to  100  for  Link  16 
JTIDS/MIDS/TADIL  J. 

4.  Sample  Rate.  The  sample  rate  shall  be  set  to  zero. 

5.  Data  Length.  This  field  shall  contain  the  length  of  data  in  bits  beginning  after  the  samples  field. 

6.  Samples.  This  field  shall  be  set  to  zero. 

7.  Data  Field.  The  JTIDS  Network  header  portion  of  the  Data  Fields  of  the  Signal  PDU  shall  be  set  as  follows: 

8.  Net  Number.  This  field  is  an  8-bit  unsigned  integer,  and  is  used  to  create  virtual  sub-circuits  within  NPG  for  stacked 
nets  or  between  NPGs  for  multi-net. 

9.  Network/Needline  Participation  Group  (NPG)  Number.  This  field  is  a  16-bit  unsigned  integer  (0-511)  used  to 
segregate  information  within  a  JTIDS/MIDS  network.  It  creates  virtual  networks  of  participants. 


10.TSEC  CVLL.  This  field  is  an  8-bit  unsigned  integer,  and  is  used  for  transmission  security,  and  allows  for  simulated 
crypto  netting.  For  TSA  Mode  0-2  this  record  is  not  required  and  the  field  is  set  to  “all  F’s”  indicating  a  no 
statement/wildcard. 

1  l.MSEC  CVLL.  This  field  is  an  8-bit  unsigned  integer,  and  is  used  for  message  security,  is  used  in  conjunction  with 
the  TSEC  CVLL,  and  allows  for  simulated  crypto  netting.  For  TSA  Mode  0-2  this  record  is  not  required  and  the 
field  is  set  to  “all  F’s”  indicating  a  no  statement/wildcard. 

12. Message  Type  Identifier.  This  field  specifies  the  format  for  the  type  of  Link  16  message  in  the  PDU.  This  field  shall 
be  set  with  an  enumeration  in  accordance  with  Table  4. 


Table  4:  Message  Type  Identifiers 

Message  Type 

Enumeration 

JTIDS  Header/Messages 

0 

RTT  A/B 

1 

RTT  Reply 

2 

JTIDS  Voice  CVSD 

3 

JTIDS  Voice  LPC10 

4 

JTIDS  Voice  LPC12 

5 

JTIDS  LET 

6 

VMF 

7 

13. Time  Slot  ID.  For  TSA  level  0-1,  this  field  is  set  to  zero.  This  field  is  a  32-bit  unsigned  integer,  and  shall  contain 
time  slot  information  for  time  slot  and  epoch  number  in  accordance  with  REF.  5.  Time  Slot  number  is  bits  0  -  16. 
Time  Slot  0  represents  time  slot  A-l,  time  slot  98303  represents  C-32767.  When  the  epoch  is  112,  the  last  valid  time 
slot  is  45151.  Bits  17  -  23  are  padding  and  set  to  1  for  level  3.  Bits  24-31  are  the  epoch  number.  An  epoch  is  12.8 
minutes  long,  and  there  are  1 12.5  epochs  in  a  24-hour  day. 

Table  5  shows  the  format  for  the  Signal  PDU  for  JTIDS  simulation. 


Table  5:  SIGNAL  PDU  for  TADIL  J 


Field 

Size 

(bits) 

Signal  PDU  Fields 

Valid 

Range 

Description 

96 

PDU 

Header 

Protocol  Version 

8  bit 

enumeration 

Exercise  ID 

8  bit  unsigned 
integer 

PDU  Type 

8  bit 

enumeration 

Protocol  Family 

8  bit 

enumeration 

Timestamp 

32  bit  unsigned 
integer 

Length 

16  bit  unsigned 
integer 

Padding 

16  bits  unused 

48 

Entity  ID 

Site 

16  bit  unsigned 
integer 

Table  5:  SIGNAL  PDU  for  TADIL  J 


Field 

Size 

(bits) 

Signal  PDU  Fields 

Valid 

Range 

Description 

Application 

16  bit  unsigned 
integer 

Entity 

16  bit  unsigned 
integer 

16 

Radio  ID 

16  bit  unsigned 
integer 

Shall  contain  the  ID  of  the  radio 
transmitting  the  signal. 

16 

Encoding 

Scheme 

16  bit 

enumeration 

Bits  0-13  shall  contain  the  number 
of  J-words  not  including  the  JTIDS 
header.  Bits  14-15  shall  contain  the 
value  1  to  indicate  an  encoding 
class  raw  binary  data 

16 

TDL  Type 

16  bit 

enumeration 

This  field  shall  be  set  to  100  for 
Link  16  JTIDS/MIDS/TADIL  J 

32 

Sample 

Rate 

32  bit  integer 

This  field  shall  be  set  to  0 

16 

Data 

Length 

16  bit  integer 

This  field  shall  contain  the  length 
of  data  in  bits  beginning  after  the 
samples  field. 

16 

Samples 

16  bit  integer 

This  field  shall  be  set  to  0 

160 

JT1DS 

Network 

Header 

NPG  Number 

16  bit  unsigned 
integer 

0-511 

Network/Needline  Participation 
Group  (NPG)  Number.  Used  to 
segregate  information  within  a 
JTIDS/MIDS  network.  Creates 
virtual  networks  of  participants. 

Net  Number 

8  bit  unsigned 
integer 

0-127 

Network  Number.  Used  to  create 
virtual  sub-circuits  within  NPG  for 
stacked  nets  or  between  NPGs  for 
multi-net. 

TSEC  CVLL 

8  bit  unsigned 
integer 

0-127,  FF 

Transmission  Security,  an  integer 
identification  of  the  crypto  variable 
used  for  JTIDS  transmission 
encryption.  This  variable  allows  for 
simulated  crypto  netting.  All  F’s  in 
this  field  shall  indicate  a  no 
statement/wildcard. 

MSEC  CVLL 

8  bit  unsigned 
integer 

0-127,  FF 

Message  Security,  an  integer 
identification  of  the  crypto  variable 
used  to  encode  the  JTIDS  message. 
This  variable  allows  for  simulated 
crypto  netting.  All  F’s  in  this  field 
shall  indicate  a  no 
statement/wildcard. 

Table  5:  SIGNAL  PDU  for  TADIL  J 


Field 

Size 

(bits) 

Signal  PDU  Fields 

Valid 

Range 

Description 

JTIDS  Network 
Header  (Con’t) 

Message  Type 
Identifier 

8  bit 

enumeration 

Determines  whether  normal  JTIDS 
header  and  message,  RTT  A/B, 

RTT  Reply,  JTIDS  Voice,  LET 
JTIDS,  or  VMF  follows.  See  table 
5.2.2  for  message  type  identifier 
enumerations 

Padding 

16  bits 

0 

Set  to  0 

Time 

Slot  ID 

Time 

Slot 

Number 

Bits  0-16 

0-98303 

Time  Slot  number;  Time  Slot  0 
represents  time  slot  A-l,  time  slot 
98303  represents  C-32767.  When 
the  epoch  is  112,  the  last  valid  time 
slot  is  45151  (end  of  the  day) 

Padding 

Bits  17-23 

0 

Set  to  0 

Epoch 

Number 

Bits  24-31 

0-112 

An  epoch  is  12.8  minutes  long, 

1 12.5  Epochs  in  a  24  hour  day.  Part 
of  time  slot  identification 

Perceived 

Transmit  Time 

64  bit  unsigned 
integer 

NTP  timestamp  format—  NTP 
timestamps  are  represented  as  a  64- 
bit  unsigned  fixed-point  number,  in 
seconds  relative  to  Oh  on  1  January 
1900.  The  integer  part  is  in  the  first 
32  bits  and  the  fraction  part  in  the 
last  32  bits.  The  precision  of  this 
representation  is  about  200 
picoseconds,  which  should  be 
adequate  for  even  the  most  exotic 
requirements.  See  RFC1305  for 
detailed  format.  All  F’s  in  this  field 
shall  indicate  a  no 
statement/wildcard. 

TADIL  J  Message  Data 

The  message  data,  corresponding  to 
the  appropriate  message  type  and 
described  in  Reference  1 . 

6  Implementation  of  Link  16  under  the  HLA 

Link  16  TDL  simulations  are  almost  always  part  of  a  wider  simulation  -  such  simulations  are  used  for  many  purposes 
including  system  development,  test  &  evaluation  and  training.  It  is  therefore  almost  certain  that  the  HLA  implementation  of 
the  Link  16  protocol  will  form  part  of  a  larger  Federation  Object  Model  (FOM).  The  HLA  implementation  of  Link  16  is 
therefore  defined  as  a  Base  Object  Model  (BOM),  as  described  in  BOM  Study  Group  Final  Report:  (SISO-REF-005-2001). 
A  BOM  is  defined  as  "a  single  aspect  of  simulation  interplay  that  can  be  used  as  a  building  block"  within  a  FOM. 


The  Link  16  BOM  is  described  in  the  Object  Model  Template  (OMT).  The  standard  for  HLA  is  IEEE  1516 — 2000 
(Reference  2)  in  which  the  OMT  is  put  forth  in  extensible  Markup  Language  (XML).  However,  at  the  time  of  writing, 
many  federations  still  use  the  older  HLA  1.3  (Reference  3)  pre-XML  OMT  format.  In  order  to  facilitate  implementation, 
two  versions  of  the  BOM  have  been  created.  The  file  Link  1 6-BOM. omd  contains  the  HLA  1.3  OMT  tables.  These  tables 
are  reproduced  in  Annex  A  of  this  standard.  A  second  file,  linkl6bom.xml,  complies  with  the  OMT  XML  format  found  in 
Ref.  2.  Both  files,  as  well  as  the  complete  OMT  tables  may  be  found  at  the  SISO  web  site  (http://www.sisostds.org). 

6.1  The  Link  16  BOM 

The  Link  16  BOM  is  intended  to  describe  how  to  implement  a  simulation  of  the  Link  16  Tactical  Data  Link  (TDL)  and  its 
associated  message  set,  TADIL  J,  within  a  High  Level  Architecture  (HLA)  simulation.  The  Link  16  BOM  is  designed  for 
integration  within  the  Federation  Object  Model  (FOM)  of  the  HLA  federation. 

6.1.1  Assumptions 

The  Link  16  BOM  assumes  that: 

1.  The  parent  FOM  contains  all  current  DIS  Transmitter  PDU  parameters  as  part  of  its  object  class  hierarchy. 

2.  The  parent  FOM  contains  all  current  DIS  Signal  PDU  parameters  as  part  of  its  interaction  class  hierarchy. 

6.1.2  Naming  Convention 

Conventions  within  the  Link  16  BOM  in  OMT  1.3  format  follow  those  adopted  by  the  RPR  FOM.  These  conventions  are 
intended  to  address  some  of  the  OMT  1.3  format  shortcomings,  which  have  been  addressed  in  the  IEEE  1516.2 
specification.  These  include: 

1 .  All  names  have  the  initial  letter  of  each  word  capitalized. 

2.  All  enumeration  names  end  in  the  text  "Enum"  followed  by  a  number.  The  number  indicates  the  number  of  bits  in 
the  enumerated  value. 

3.  All  complex  data  type  names  end  in  the  text  "Struct". 

6.1.3  Levels  of  Fidelity 

The  HLA  levels  of  fidelity  are  directly  equivalent  to  the  corresponding  DIS  levels  of  fidelity  as  defined  in  section  5.1.2. 

6.1.4  Time  Synchronization 

The  HLA  time  synchronization  mechanism  is  directly  equivalent  to  the  corresponding  mechanism  for  DIS  as  defined  in 
section  5.1. 

6.1.5  Protocol  Implementation  Details 

This  section  defines  how  Link  16  BOM  compliant  federates  are  to  implement  the  Link  16  protocol.  The  HLA  protocol 
implementation  details  are  directly  equivalent  to  the  corresponding  details  for  DIS  as  defined  in  section  5.2. 

6.1.6  Object  Class  Data 

The  Link  16  BOM  defines  no  new  object  classes.  Instead  the  BOM  defines  a  single  complex  data  type 
(JTIDSTransmitterStruct)  that  corresponds  to  the  modulation  parameters  in  the  DIS  Transmitter  PDU  defined  in 
section  5.2.1.  An  attribute  of  this  complex  data  type  should  be  added  to  the  object  class  in  the  parent  FOM  corresponding 
to  the  DIS  Transmitter  PDU.  Modulation  parameters  of  the  Transmitter  PDU  shown  in  section  5.1,  Table  3,  map  to  the 
fields  of  the  JTIDSTransmitterStruct  complex  data  type  attribute,  shown  in  Annex  A. 5.  Parent  object  class  fields 
are  also  modified  such  that  they  refer  to  the  corresponding  Transmitter  PDU  fields. 

NOTE:  For  a  RPR  FOM  implementation,  an  attribute  of  the  JTIDSTransmitterStruct  complex  data  type  should  be 
added  to  the  RadioTransmitter  object  class. 


6.1.7  Interaction  Class  Data 


The  Link  16  BOM  adds  a  family  of  interactions  that  will  support  future  TDL  implementation  of  other  datalinks.  The 
family  of  interactions  is  a  hierarchy  in  which  the  BOM’s  base  class  for  this  interaction  is  a  generic  class  -  the 
TDLBinaryRadioSignal  interaction.  This  class  is  an  empty  class,  contains  no  parameters,  and  is  neither  publishable 
nor  subscribable.  The  specific  parameters  are  properties  of  the  various  subclasses  of  this  generic  base  class,  and  it  is  these 
subclasses  that  are  published  and  subscribed  to. 

The  Linkl6RadioSignal  interaction,  shown  in  Annex  A.3,  which  is  a  subclass  of  the  TDLBinaryRadioSignal 
interaction,  contains  the  JTIDS  Network  Header  Parameters  as  shown  in  table  5.  The  JTIDSMessageRadioSignal 
interaction  contains  the  Link  16  message  data.  Additional  interactions  shown  in  Annex  A.3  define  the  other  types  of  Link 
16  messages.  Parent  object  class  fields  are  also  modified  such  that  they  refer  to  the  corresponding  Signal  PDU  fields. 

The  Link  16  BOM  design  is  such  that  the  TDLBinaryRadioSignal  interaction  becomes  a  subclass  of  the  parent 
FOM's  equivalent  of  the  DIS  Signal  PDU.Modulation  parameters  of  the  Signal  PDU  map  to  the  fields  of  the 
JTIDSTransmitterStruct  complex  data  type  attribute  (see  section  5.4).  Parent  object  class  fields  are  also  modified 
such  that  they  refer  to  the  corresponding  Signal  PDU  fields. 

NOTE:  For  a  RPR  FOM  implementation,  the  TDLBinaryRadioSignal  class  becomes  a  subclass  of  the  RPR  FOM 
RawBinaryRadioSignal  interaction  class;  this  is  done  in  order  to  allow  access  to  the  HostRadioIndex  parameter 
in  the  RawBinaryRadioSignal  interaction  class.  The  HostRadioIndex  parameter  ties  the  Link  16  message  to  a 
specific  Host  and  Radio  Transmitter. 

6.1.8  BOM  Implementation 

The  BOM  implementation,  in  OMT  1.3  format,  is  described  in  annex  A.  For  RPR  FOM  1.0  (Reference  5), 

SpreadSpectrumStruct  complex  data  type  and  TDLBinaryRadioSignal  should  be  added  to  the  Radio 
Transmitter  Object  Class.  For  RPR  FOM  2.0  (Reference  6),  the  SpreadSpectrumStruct  complex  data  type  already 
exits.  Therefore,  the  field  TDLBinaryRadioSignal  shall  be  added  to  the  SpreadSpectrumStruct  complex  data 
type,  as  shown  in  Annex  A.  5. 

An  attribute  (JTIDSTransmitterData)  of  complex  data  type  JTIDSTransmitterStruct  is  added  to  the  RPR 
FOM  Radio  Transmitter  object  class.  The  Linkl 6RadioSignal  interaction  class  is  added  as  a  subclass  of  a  new 
interaction  class,  the  TDLBinaryRadioSignal  interaction,  which  itself  is  a  subclass  of  the  RPR  FOM's 
RawBinaryRadioSignal  interaction  class. 


Table  6;  Link  16  BOM  Interactions  in  the  RPR-FOM 


RadioSignal 

ApplicationSpecifcRadioSignal 

DatabaselndexRadioSignal 

EncodedAudioRadioSignal 

RawB  inary  Radio  S  ignal 

TDLBinaryRadioSignal 

Link  1 6RadioSignal 

JTIDSMessageRadioSignal 
RTTABRadioSignal 
RTTReplyRadioSignal 
JTIDSVoiceCVSDRadioSignal 
JTIDSVoiceLPC  1  ORadioSignal 
JTIDS  VoiceLPC  1 2RadioSignal 
JTIDSLETRadioSignal 
VMFRadioSignal 

NOTES; 

1.  The  addition  of  the  TDLBinaryRadioSignal  interaction  class  and  its  associated  subclasses  was  necessary 

because  of  the  RPR  FOM  implementation  limitations  of  the  DIS  Signal  PDU.  Section  5.2.2  defines  the  DIS  Signal  PDU 
used  for  all  Link  16  messages  in  a  Raw  Binary  Signal  PDU.  The  RPR  FOM  equivalent  of  this  PDU  type  (the 
RawBinaryRadioSignal  interaction  class)  contains  a  parameter,  called  SignalData,  containing  one  or  more 


octets  containing  the  signal  data.  If  the  SignalData  octet  based  storage  scheme  to  store  Link  16  messages  was  used  the 
Link  16  message  would  be  lost  during  byte  swapping.  The  implementation  is  defined  such  that  the  Link  16  interaction 
becomes  a  subclass  of  the  RawBinaryRadioSignal  interaction  to  ensure  the  SignalData  storage  is  not  used.  Data 
integrity  is  achieved  by  moving  the  Link  16  message  storage  into  the  lowest  level  classes  (i.e  the 

JTIDSMessageRadioSignal  ). 

2.  DIS  to  HLA  gateways  will  require  modification,  but  the  modifications  are  well  defined.  DIS  Raw  Binary  Signal 
PDUs  need  to  be  split  into  a  RawBinaryRadioSignal  interaction  or  the  appropriate  Link  16  interaction  class, 
depending  on  the  TDL  type.  Conversely,  a  HLA  to  DIS  gateway  must  merge  both  interaction  types  into  a  single  DIS 
Signal  PDU. 


ANNEX  A: 


LINK  16  BASE  OBJECT  MODEL  (BOM)  OMT  1.3  TABLES 


A.l  OBJECT  MODEL  IDENTIFICATION  TABLE 


Category 

Information 

Name 

Link  16  BOM 

Version 

vl.O  Draft  2 

Date 

9/9/2002 

Purpose 

Link  16  Base  Object  Model  (BOM) 

Application  Domain 

C4ISR  &  C2  platform  simulations 

Sponsor 

SISO 

POC  (Title,  First,  Last) 

Mr  Graham  C  Shanks 

POC  Organization 

AMS 

POC  Telephone 

+44  1383  828062 

POC  Email 

graham.shanks@amsjv.com 

A.2  OBJECT  INTERACTION  TABLE 


Interactionl 

Interaction! 

Interaetion3 

Interaction 

Parent  (N) 

TD  LB  inary  RadioSignal 
(N) 

Linkl6RadioSignal  (R) 

JTIDSMessageRadioSignal  (IR) 
RTTABRadioSignal  (IR) 
RTTReplyRadioSignal  (IR) 
JTIDSVoiceCVSDRadioSignal  (IR) 
JTIDSVoiceLPC  1  ORadioSignal  (IR) 
JTID  S VoiceLPC  1 2RadioSignal  (IR) 
JTIDSLETradioSignal  (IR) 
VMFRadioSignal  (IR) 

DRAFT 

SISO-STD-002-V2.9.6 
7  March  2005 


.3  PARAMETER  TABLE 


Interaction 

Parameter 

Datatype 

Cardinalit 

y 

Units 

Resolution 

Accuracy 

Accuracy 

Condition 

Routing 

Space 

JTIDSLETradioSignal 

LETHeader 

LETHeaderStruct 

l 

N/A 

N/A 

N/A 

N/A 

N/A 

TADILJMessage 

TADILJWordStmct 

i+ 

N/A 

N/A 

N/A 

N/A 

JTIDSMessageRadioSignal 

JTIDSHeader 

JTIDSHeaderStruct 

l 

N/A 

N/A 

N/A 

N/A 

N/A 

TADILJMessage 

TADILJWordStmct 

i+ 

N/A 

N/A 

N/A 

N/A 

JTIDSVoiceCVSDRadioSignal 

JTIDSHeader 

JTIDSHeaderStruct 

l 

N/A 

N/A 

N/A 

N/A 

N/A 

Data 

octet 

29+ 

N/A 

N/A 

perfect 

always 

JTIDSVoiceLPCIORadioSignal 

JTIDSHeader 

JTIDSHeaderStruct 

1 

N/A 

N/A 

N/A 

N/A 

N/A 

Data 

octet 

29+ 

N/A 

N/A 

perfect 

always 

JTIDSVoiceLPC12RadioSignal 

JTIDSHeader 

JTIDSHeaderStruct 

1 

N/A 

N/A 

N/A 

N/A 

N/A 

Data 

octet 

29+ 

N/A 

N/A 

perfect 

always 

Linkl  6RadioSignal 

NPGNumber 

unsigned  short 

1 

N/A 

N/A 

perfect 

always 

N/A 

NetNumber 

octet 

1 

N/A 

N/A 

perfect 

always 

TSEC  CVLL 

octet 

1 

N/A 

N/A 

perfect 

always 

MSEC  CVLL 

octet 

1 

N/A 

N/A 

perfect 

always 

TimeSlotID  [31 

unsigned  long 

1 

N/A 

N/A 

perfect 

always 

PerceivedTransmitTime  [2] 

long  long 

1 

N/A 

N/A 

perfect 

always 

RTTABRadioSignal 

RTTAB 

RTTAB  Struct 

1 

N/A 

N/A 

N/A 

N/A 

N/A 

RTTReplySignal 

RTTReply 

RTTReplyStruct 

1 

N/A 

N/A 

N/A 

N/A 

N/A 

VMFRadioSignal 

JTIDSHeader 

JTIDSHeaderStruct 

1 

N/A 

N/A 

N/A 

N/A 

N/A 

TADILJMessage 

TADILJWordStmct 

1+ 

N/A 

N/A 

N/A 

N/A 
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A.4  ENUMERATED  DATATYPES  TABLE 


Identifier 

Enumerator 

Representation 

JTIDSPrimaryModeEnum8  [1] 

NTR 

1 

JTIDSUnitParticipant 

2 

JTIDSSecondaryModeEnum8  [1] 

None 

0 

NetPositionReference 

1 

PrimaryNavigationController 

2 

SecondaryNavigationController 

3 

JTID  S  SynchronizationStateEnum8  [  1  ] 

CourseSynchronization 

2 

FineSynchronization 

3 

TSALevelEnum8  [1] 

LowF  idelityLevelO 

0 

LowF  idelityLevel  1 

1 

MediumFidelityLevel2 

2 

MediumFidelityLevel3 

3 

HighF  idelityLeveM 

4 

A.5  COMPLEX  DATATYPES  TABLE 


Complex  Datatype 

Field  Name 

Datatype 

Cardinality 

Units 

Resolution 

Accuracy 

Accuracy 

Condition 

JTIDSHeaderStruct 

Data 

octet 

6 

N/A 

N/A 

perfect 

always 

JTID  ST ransmitterStruct 

T  imeSlotAlocationMode 

TSALevelEnum8 

1 

N/A 

N/A 

N/A 

N/A 

TransmittingT  erminalPrimaryMode 

JTID  SPrimaryModeEnum8 

1 

N/A 

N/A 

N/A 

N/A 

T  ransmittingT  erminal  Secondary  Mode 

JTID  S  S  econdaryModeEnum8 

1 

N/A 

N/A 

N/A 

N/A 

SynchronizationState 

JTID  S  SynchronizationStateEnum8 

1 

N/A 

N/A 

N/A 

N/A 

N  etworkSynchronizationID 

unsigned  long 

1 

N/A 

N/A 

perfect 

always 

LETHeaderStruct  [4] 

Data 

octet 

6 

N/A 

N/A 

perfect 

always 

RTTAB  Struct  [51 

Data 

octet 

6 

N/A 

N/A 

perfect 

always 

RTTReplyStmct  [6] 

Data 

octet 

6 

N/A 

N/A 

perfect 

always 

TADILJWordStruct  [7] 

Data 

octet 

10 

N/A 

N/A 

perfect 

always 

SpreadSpectmmStmct 

TDLBinaryRadioSignalFlag 

octet 

1 

N/A 

N/A 

perfect 

always 
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A.6  NOTES  TABLE 


ID 

Text 

1 

This  is  an  8-bit  enumeration 

2 

NTP  timestamp  format—  NTP  timestamps  are  represented  as  a  64-bit  unsigned  fixed-point  number,  in 
seconds  relative  to  Oh  on  1  January  1900.  The  integer  part  is  in  the  first  32  bits  and  the  fraction  part  in  the 
last  32  bits.  The  precision  of  this  representation  is  about  200  picoseconds,  which  should  be  adequate  for  even 
the  most  exotic  requirements.  See  RFC1305  for  detailed  format.  All  F's  in  this  field  shall  indicate  a  no 
statement/wildcard 

3 

See  TimeSlot  ID  structure  in  Table  5.2.4 

4 

See  LET  Message  Header  structure  in  Table  5.2.1 1 

5 

See  RTT  A/B  Message  structure  in  Table  5.2.6 

6 

See  RTT  Reply  Message  structure  in  Table  5.2.7 

7 

See  TADIL  J  Message  Bit  Orientation  in  Table  5.2.3 
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